Using Meta-Level Techniques to Personalize O-O Applications

In this paper we discuss how to use reflective techniques for personalizing object-oriented applications. This approach is based on a clear separation of concerns, namely: base application functionality, user profile management, and personalization rules; our approach simplifies the evolution of Web Applications when adding personalization features (such as recommendations, special offers, individual interfaces, etc). We first explain why personalization functionality should be dealt by separating concerns. Next we introduce a simple example and focus on different personalization patterns, emphasizing on behavior personalization. We also show which design structures are the most appropriated for obtaining seamless extensions to existing software. We finally discuss some further aspects such as using meta-level constructs for designing personalized applications. 1-Introduction Personalization has become a very important issue in software applications ranging from word-processors to e-commerce and other Web Software. Building customized software is not a new problem; however, the increasing popularity of the World Wide Web, and the evolution of hardware appliances make personalization a hotter topic. Designing personalized software may imply dealing with different concerns (modeling the user, implementing personalized interfaces, modeling customization rules, implementing complex algorithms, etc) that must be seamlessly integrated. However, while user modeling, profile derivation and personalization algorithms (such as collaborative filtering) have been extensively discussed in the literature [Oreizy 99], less attention has been paid to the modeling and design process of this kind of software. In this position paper we claim that personalization is an interesting and critic aspect of an application’s evolution. This is true not only because of the difficulties inherent to the problem (such as integration of concerns) but also because of the evolvable nature of personalized applications. More precisely, as personalization requirements and policies change over time, software maintenance becomes a nightmare. We have been studying the problem of web applications’ evolution; we have analyzed design problems related with personalization and identify usual personalization patterns [Rossi 01a, Rossi 01b]. In this position paper we present a solution to the personalization puzzle that improves separation of concerns. The structure of the paper is as follows: We first discuss the problem of designing personalized applications in the context of applications’ evolution and why separation of concerns is a key solution for coping with this problem. Next we show a first approach, by describing the right separation of concerns and how a generic model can be obtained. Finally we will go one step further and show how thinking of personalization from the meta level point of view will give a better approach to address a generic framework for personalizing applications. Though we exemplify with applications in the e-commerce domain, the approach is general enough to be applied in other domains. For the sake of conciseness we do not address in this position paper our approach for user modeling; instead we focus on the implementation of personalized behaviors. 2-Designing Personalized Software We can think of personalization as adding new concerns to the problem of application’s design, namely the user (or role) profile and the personalization rules. Not only we need to model the basic application domain (e.g. an electronic store) but also we have to model the user and the ways in which this model will interact with the underlying application model (roughly speaking the personalization rules). As previously stated we think that this problem is related with the application’s evolution because requirements related with personalization tend to change over time. Let us suppose that we are building an e-commerce application and we want to keep track of how many times each user has bought some sort of product, so that we can perform some site statistics later. Even though this update is fairly simple, an interesting discussion might rise to decide which object of the model should be responsible for triggering the update in the user profile (and of course to decide what the user profile should be responsible of), or to figure out were the logic of that update should be coded. But most answers that may come up will not be completely satisfactory as we will need to add new behaviors to domain objects; behaviors that, by the way, do not belong to the original objects’ responsibilities. Suppose that the marketing department decides that we should record every product the user has bought and later, because of policy changes, only those products that fulfill some condition. We are faced to repeatedly change code that has already been worked out. Unfortunately the pace of changes related with personalization (or other customization features) may be fast or even hysteric. This example gets even worse when other personalization features that involve complex rules and user profile data are introduced (think for example on price discounts, recommendation algorithms and personalized check-out processes). It is important to note that in the current state of affairs in the business world, upgrades related with personalization are usually unpredictable and we have to deal with them (as with most changes in business rules) in a quick and efficient way. 3-Decoupling concerns using wrappers As we stated before, we should try to avoid mixing the basic application’s logic with personalization code. In [Rossi 01c] we presented a set of micro-architectures to address this problem, showing how to achieve a well-defined separation of concerns. The idea (originally devised for e-commerce applications) is based on the interception of messages to objects whose behavior has to be personalized by using a wrapper between the personalized object and the message sender. The wrapper should collaborate with other personalization-specific objects to decide how to answer to that message. As an example, suppose we want to personalize the price of a product depending on an algorithm (that may be even different according to the user’s profile). In Figure 1 we present a first approach for solving the personalization problem. Notice that there is a clear separation of concerns; Class Product is designed (and evolves) without personalization features in mind, while all personalization issues are handled by objects that do not belong to the core application’s model.